In modern communication systems, load sharing has become an important role for efficiently distributing traffic in a communication network among multiple routes or towards different nodes which may handle the same application with different processing capacities. Load sharing approaches directed to distributing traffic to different receiving network nodes are based on the assumption that a communication node is capable of distributing traffic among the receiving network nodes according to their processing capacity which results in a capacity-weighted load sharing. An example of such a load sharing approach is the M3UA (Message Transfer Part Level 3 User Adaptation Layer) signaling gateway process (SGP) which distributes traffic to an M3UA application server (AS) in a load sharing mode. Conversely, load sharing approaches which are based on traffic distribution among different paths assume that a distributing communication node forwards messages to a single receiving network node through a number of alternative signaling routes or paths which are respectively associated with a capacity. An example of such a load sharing approach may be the M3UA ASP connecting to a remote SS7 (Signaling System No.7) signaling end point (SEP) through a number of M3UA SGPs.
According to conventional load sharing approaches, the messages belonging to the same message flow may be forwarded to the same receiving network node over the same route. In the case of connection-oriented transport protocols such as SUA or TCP, forwarding may achieved by means of connection-awareness of the distributing communication node, which results in a stateful distribution. In some cases, the identity of the receiving network node terminating the connection may be encoded in some transport protocol parameter so that the distributor may forward all subsequent messages directly to the proper receiving network node without having to maintain a connection state, which results in a stateless distribution.
For connection-less transport protocols, however, a message flow may be not uniquely identifiable by means of protocol parameters directly visible to distributing, i.e. load sharing, communication node such as M3UA. In this case, packet inspection may be necessary on the communication node to determine the message flow and select the proper recipient node or route.
In SS7 and SIGTRAN (M3UA) networks, the SLS (Signaling Link Selection) parameter may be used for load sharing messages flows among in several ways. The M3UA SGP may e.g. load share message flows among the ASPS in an AS in order to ensure that all messages in the flow are transmitted to the same ASP. The SEP, ASP, STP or SGP may load share message flows among routes/links towards a given destination in order to keep an in-sequence delivery to the destination. For these purposes, the application layer may provide an SLS value with every message to be sent. The same SLS value may be used for all messages pertaining to a specific signaling transaction, e.g. a call in case of ISUP, or a TCAP transaction, which may require in-sequence delivery. The SLS parameter may be included in the MTP/M3UA header and used for load sharing in every hop along the signaling route.
However, according e.g. to the ITU-T (ETSI) standard, the SLS is only a four bit parameter, which means it may not be used for load sharing among more than 16 ASPS or routes. Another problem may arise with respect to re-routing. When an ASP activates itself on SGP, or if a route becomes available, then a controlled re-routing may be started. Therefore, the complete traffic is stored in a controlled re-routing buffer until a timer expires. The re-distribution of SLS values to available ASPS or routes, the so-called change of load sharing pattern, is an implementation issue and may not efficiently maintaining capacity weights and minimizing re-routing complexity.